System and method for providing a virtual binding for a worm storage system on rewritable media

ABSTRACT

A virtual binding system ensures that the WORM logic for protecting data immutability cannot be circumvented, effectively guaranteeing WORM property of a WORM storage system composed of rewritable magnetic hard disks. To close the security hole between the rewritable media and the WORM logic, virtual binding securely authenticates the legitimacy of a WORM logic controller before granting data access on a WORM storage media. Furthermore, the system verifies the legitimacy of the WORM logic controller during data access. This approach virtually binds together the WORM logic controller and the WORM storage media even though the WORM logic controller and the WORM storage media may be physically separate.

FIELD OF THE INVENTION

The present invention generally relates to write-once read-many (WORM)storage and in particular to a WORM storage system utilizing rewriteablemedia.

BACKGROUND OF THE INVENTION

As critical data are increasingly stored in electronic form, it isimperative that the critical data be stored reliably in a tamper-proofmanner. Furthermore, a growing subset of electronic data (e.g.,electronic mail, instant messages, drug development logs, medicalrecords, etc.) is subject to regulations governing long-term retentionand availability of the data. Recent high-profiled accountability issuesat large public companies have further caused regulatory bodies such asthe Securities and Exchange Commission (SEC) to tighten theirregulations. For instance, Securities Exchange Commission Rule 17a-4,which went into effect in May 2003, specifies storage requirements foremail, attachments, memos, and instant messaging as well as routinephone conversations.

A requirement in many such regulations is that data must be storedreliably in non-erasable, non-rewritable storage such that the data,once written, cannot be altered or overwritten. Such storage is commonlyreferred to as WORM (Write-Once Read-Many) storage as opposed to WMRM(Write-Many Read-Many) storage, which can be written many times.

Conventional WORM storage media comprises WORM tape, ablative WORMoptical disk, and magnetic WORM disk. For ablative WORM-based opticalCD, the non-overwritable property is inherent in the physical media.Although conventional WORM technology has proven to be useful, it wouldbe desirable to present additional improvements. Writing data toablative WORM optical disk invokes a permanent change to media itselfand cannot be reversed. However, for existing tape-based and magnetichard-disk based WORM storage system, the media is rewriteable and theWORM property is guaranteed in microcode rather than by media itself.

Guaranteeing the WORM property in microcode rather than by the mediaintroduces a potential trust problem. The data stored on the rewritablemedia can be modified by malicious applications through another I/Ointerface that does not support WORM-safe microcode. Conventionalrewritable media has no means of protection to prevent data from beingoverwritten. Once the rewritable media is disconnected from the mediadrive (disk controller or tape drive) that implements the WORM feature,the data on the media can be overwritten by non-WORM tape drives or diskcontrollers.

The use of rewritable media as WORM storage is attractive because therandom access performance of magnetic hard disks is orders of magnitudeimproved over that of optical WORM disks. In practice, the fast readperformance of rewritable magnetic disks is desirable to meet the searchrequirement of the current data regulations. One conventional approachto providing WORM storage with rewritable media is to lock the wholestorage enclosure (disks, WORM controllers) physically together to avoidtampering. This approach protects the rewritable media from beingaltered by intruding non-WORM controllers. However, a super key caneasily tamper a physical lock. This approach further imposesdifficulties and overhead on storage management.

WORM properties of a storage system can be guaranteed on a softwarelevel, a firmware level, or a media level. Implementing a WORM propertyat the media level (e.g., inside hard drives) requires significantchanges to the existing commodity hardware. Data storage and accessregulations are continually changing, requiring flexibility inconfiguring WORM storage. The overhead of altering any logic in hardwareis usually larger than that of upgrading microcode or software. However,conventional rewritable storage such as a hard drive typically does notprovide a programmable environment. Consequently, a WORM storage basedon customized hard drives may be unable to meet changes in dataregulations.

Implementing a WORM property in a programmable level such as that of afirmware level or software level provides the flexibility required tocomply with continually changing data regulations. However, once thebinding of the media and the WORM logic is implemented in the firmwarelevel or the software level, the media content can be easily altered.

One conventional approach uses a physical lock on an enclosure in whichthe components of the WORM storage system reside. The physical lockensures that the rewritable hard drives and the WORM logic implementedin a storage controller or a processor are physically bound together.Consequently, a malicious adversary has no opportunity to tamper thehard disks through a non-WORM storage controller. However, theanti-tampering barrier of a physical lock is low. For example, anintruder can use a super key to open the locked enclosure. Anotherconventional approach uses magnetic latches to lock the rewritable disksinto an enclosure together with the WORM logic. Such physical binding,however, requires extensive changes to current systems and limitsincremental growth.

Another conventional approach uses password verifications to bind theWORM logic with the rewritable storage. This approach requires nohardware modifications. Certain commodity hard drives already havebuilt-in hard-drive password protection. However, authenticationpasswords can be easily tampered. The following is a scenario describinghow an intruder tampers a password-based authentication. Assume the WORMlogic is implemented in the firmware of a disk controller. Suppose acontroller and disk pair comprises a controller C₀ and a disk D₀. Amalicious controller and disk pair comprises a malicious controller C₁and a malicious disk D₁.

The controller C₀ and disk D₀ operate in an open, accessible environmentor cabinet such that disks can be freely plugged in and out. Theintruder removes the disk D₀ from the cabinet. The intruder inserts themalicious disk D₁ to steal the password of the controller C₀. Once diskD₁ has this password, the disk D₁ passes it the password to maliciouscontroller C₁. Now the intruder can use this password to authenticatemalicious controller C₁ with disk D₀ and alter the data on disk D₀.

To comply with continually changing regulations for data storage and userewritable media as WORM data storage, data management systems require aconfiguration that maximizes performance, flexibility, and growthcapability. A secure binding of WORM logic and storage media is desiredto achieve true data immutability without sacrificing ease of storagemanagement tasks such as failure recovery, etc. What is therefore neededis a system, a computer program product, and an associated method forproviding a virtual binding for a WORM storage system on rewritablemedia. The need for such a solution has heretofore remained unsatisfied.

SUMMARY OF THE INVENTION

The present invention satisfies this need, and presents a system, aservice, a computer program product, and an associated method(collectively referred to herein as “the system” or “the presentsystem”) for providing a virtual binding for a WORM storage system onrewritable media. The virtual binding ensures that WORM logic protectingdata immutability cannot be circumvented.

The present system comprises a WORM logic controller and a WORM storagemodule. The WORM storage module resides in a storage enclosure with arewritable media. The WORM logic of the WORM logic controller can beimplemented in any form such as, for example, application software, filesystem software, or firmware of a storage controller. As a WORM logiccontroller, the WORM logic is realized in a programmable storagecontroller to avoid hardware modifications to the rewritable media ofthe WORM storage module.

To close any security holes between the WORM storage module and the WORMlogic controller, a controller authenticator of the WORM storage modulesecurely authenticates legitimacy of the WORM logic controller beforegranting data access to the rewritable media. Similarly, a storageauthenticator of the WORM logic controller authenticates the WORMstorage module. The present system virtually binds the WORM logiccontroller and the WORM storage module together even though the WORMlogic controller and the WORM storage module may be physicallyseparated. Consequently, the present system enables storage mediamobility and allows easy and secure information transfer in an open andmalicious environment. The present system further enables flexiblesystem capacity scaling and ease of storage management.

The WORM logic controller and the WORM storage module each comprise apublic key and a private key. The WORM logic controller and the WORMstorage module mutually register using their respective public key. Theregistered public key of the WORM logic controller is stored in astorage user table in the controller authenticator on the WORM storagemodule. The registered public key of the WORM storage module is storedin a controller user table in the storage authenticator on the WORMlogic controller. The WORM storage module grants media access rightsonly to a legitimate WORM logic controller authenticated by thecontroller authenticator. This authentication requirement preventsoverwriting of data in a malicious attack.

A WORM storage module that is blank and comprising an empty user tableadmits any WORM logic controller. A WORM storage module with user tablethat is not empty admits WORM logic controllers only until an associatedregistration phase closes.

The virtual binding of the present system is provided through secureauthentication. During the authentication phase, no secret informationis transmitted for authentication. Consequently, the authenticationphase of the present system is more secure than conventional passwordauthentication. Once the registration and initialization is securelyperformed, only the registered controllers can access the target harddrives. To avoid hardware modifications to existing hard disks, theauthentication logic is implemented on a customized and permanentlysealed storage enclosure. The rewritable media is permanently locked inthe sealed storage enclosure.

The present system does not rely on physical locks to bind the WORMlogic controller and the WORM storage module together. The presentsystem provides WORM protection for each WORM storage module even if theWORM storage module is disconnected from the WORM logic controller. Toachieve minimum total system cost, the present system minimizes therequired modifications to media hardware. Compared to WORM storage onmagnetic disks using mechanical lock protection, the present systemoffers improved disk mobility and system scalability.

The virtual binding seamlessly ties together the WORM logic controllerand WORM storage module for the rewritable media of a storage enclosure.With virtual binding, the present system achieves a secure WORM propertyfor a WORM storage system using rewritable media. Every user for astorage enclosure is securely authenticated before any data access isallowed. The barrier for tampering is much higher for the present systemthan that of conventional WORM storage systems relying on a physicallock or no binding at all. The present system further achieves highsystem throughput and retrieval performance.

The present system achieves ease of storage management. Virtual bindingdoes not require any physical lock or physical enclosure for security. Astorage enclosure and a WORM logic controller can join or leave astorage system through a relatively simple procedure. The present systemfurther provides flexibility in capacity scaling. Virtual binding allowsaddition of new storage enclosures at system run time.

The present system provides low total system cost. WORM logic isprogrammed in a programmable environment of the WORM logic controller.The WORM logic controller comprises a commodity storage controller orapplication software. Authentication logic for the controllerauthenticator is built in a customized storage enclosure. No hardwaremodification is required for the rewritable media. The present systemfurther provides ease of function extension. WORM logic and otherfunctions required for data compliance can be easily upgraded in aprogrammable environment.

The present system may be embodied in a utility program such as avirtual binding utility program. The present system also provides meansfor the user to identify a set of data to be stored in WORM storageprovided by the present system and then invoke the virtual bindingutility program to process and store the data in WORM storage.

BRIEF DESCRIPTION OF THE DRAWINGS

The various features of the present invention and the manner ofattaining them will be described in greater detail with reference to thefollowing description, claims, and drawings, wherein reference numeralsare reused, where appropriate, to indicate a correspondence between thereferenced items, and wherein:

FIG. 1 is a schematic illustration of an exemplary operating environmentin which a virtual binding system of the present invention can be used;

FIG. 2 is a process flow chart illustrating a method of operation of thevirtual binding system of FIG. 1;

FIG. 3 comprises FIGS. 3A, 3B, and 3C, and represents a process flowchart illustrating a method of operation of the virtual binding systemof FIG. 1 in a registration and authentication phase;

FIG. 4 is a process flow chart illustrating a method of operation of thevirtual binding system of FIG. 1 in an operation phase;

FIG. 5 is comprised of FIGS. 5A and 5B and represents a process flowchart illustrating a method of operation of the virtual binding systemof FIG. 1 in a maintenance and management phase; and

FIG. 6 is a process flow chart illustrating a method of operation of thevirtual binding system of FIG. 1 in a migration phase.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1 portrays an exemplary overall environment (a WORM storage system100) in which a system, a service, a computer program product, and anassociated method (the “virtual binding system 10” or the “system 10”)for providing a virtual binding for a WORM storage system on rewritablemedia according to the present invention may be used. System 10comprises a software programming code or a computer program product thatis typically embedded within, or installed on a computer 15.

System 10 comprises a worm logic controller 20 and a WORM storage module25. The WORM logic controller 20 comprises a storage authenticator 30for authenticating a security-enhanced storage enclosure 35. The WORMstorage module 25 comprises a controller authenticator 40 forauthenticating the WORM logic controller 20. The WORM logic controller20 and the WORM storage module 25 communicate via a network 45 throughcommunication links 50, 55, respectively. While the system 10 isdescribed for illustration purpose only in relation to network 45, itshould be clear that the WORM logic controller 20 and the WORM storagemodule 25 can communicate locally as well as remotely and may beco-located or located remote from each other.

The security-enhanced storage enclosure 35 (interchangeably referencedherein as storage enclosure 35) comprises the WORM storage module 25 anda rewritable media 60. The WORM storage module 25 controls access todata in the rewritable media 60, allowing only an authenticated WORMlogic controller 20 to have access privileges to the rewritable media60. Consequently, the process of authentication between the WORM storagemodule 25 and the WORM logic controller 20 forms a virtual binding 65that achieves a secure WORM property for the security-enhanced storageenclosure 35.

In one embodiment, additional WORM logic controllers may have access tothe rewritable media. For example, WORM logic controller A, 70, may forma virtual binding 75 through network 45. Worm logic controller A, 70,and WORM logic controller 20 are collectively referenced as WORM logiccontrollers 80 and represent any number of worm logic controllers. Themaximum number of controllers that can be registered depends on the sizeof the storage memory. In practice, the storage memory size is typicallylarge and does not pose a limitation on the number of controllers.

The rewritable media 60 comprises, for example, standard rewritable ATAor SCSI magnetic hard drives. In one embodiment, the WORM logiccontroller 20 comprises a built-in WORM logic controller 20. While theWORM logic controller 20 is described for illustration purposes only interms of a built-in WORM logic controller 20, it should be clear thatthe WORM logic of the WORM logic controller 20 can be built in anylayer. System 10 is applicable to any WORM logic implementation andstorage media binding.

The WORM storage module 25 comprises a rewritable non-volatile media (astorage memory 85). In one embodiment, the storage memory 85 comprises afew hundred bytes. The storage memory 85 stores a storage public key anda storage private key (collectively referenced as the storagepublic/private key pair). The WORM storage module 25 further comprisesthe processing power required to perform public-key and private-keybased encoding or decoding. While the worm storage module 25 isdescribed for illustration purposes only as being implemented in thesecurity-enhanced storage enclosure 35, it should be clear that the WORMstorage module 25 can be implemented in the rewritable media 60.

The WORM logic controller 20 comprises a rewritable non-volatile media(a controller memory 90). In one embodiment, the controller memory 90comprises a few hundred bytes. The controller memory 90 stores anidentifier for the WORM logic controller (further referenced herein asthe controller ID). The controller ID is optional, and is not necessaryto maintain the controller ID. The public key could alternatively serveas the controller ID. The controller memory 90 further stores acontroller public key and a controller private key (collectivelyreferenced herein as the controller public/private key pair). Thecontroller memory 90 stores an optional controller certificate. For easeof replication, the controller ID, the controller public/private keypair, or the optional controller certificate can be stored in persistentstorage other than the controller memory 90. For example, the controllerID, the controller public/private key pair, or the optional controllercertificate can be stored in a hard disk accessible only to authorizedusers.

When the WORM storage module 25 is implemented in the security-enhancedstorage enclosure 35, the mobile granularity is a security-enhancedstorage enclosure 35. The security-enhanced storage enclosure 35 isloaded with rewriteable media 60 comprising, for example, disks. Thesecurity-enhanced storage enclosure 35 is permanently sealed beforebeing shipped. Consequently, the rewritable media 60 and the WORMstorage module 25 are inseparable from the security-enhanced storageenclosure 35 and form a single entity in the WORM storage system 100.

Data access to the rewritable media 60 is locked from any attemptingWORM logic controller 20 unless the authentication process of thecontroller authenticator 40 is successful. The controller authenticator40 maintains a storage user table in the storage memory 85 comprising acontroller public key and an optional controller ID for each of the WORMlogic controllers 80 that have data access to the rewritable media 60.

The WORM storage module 25 maintains the storage private/public key pairas an identity for the WORM storage module to be authenticated by theWORM logic controller 25. In one embodiment, the WORM storage module 25further maintains a flag to indicate a registration status. WORM logiccontrollers 80 can be admitted to the WORM storage module 25 only ifregistration is open.

In one embodiment, the WORM storage module 25 and related secretinformation are replicated in the security-enhanced storage enclosure 35to avoid single point of failure. In another embodiment, thesecurity-enhanced storage enclosure 35 is made tamper-resistant to avoidphysical intrusion to the storage user table and the rewritable media60. A tamper-resistant security-enhanced storage enclosure 35 erases anyconfidential information and self-destructs if any physical intrusionoccurs to the security-enhanced storage enclosure.

System 10 can bind together in the virtual binding 65 the rewritablemedia 60 and any form of the WORM logic controller 20 (i.e., software orfirmware). For fault tolerance, the WORM storage system can comprisedual WORM logic controllers 80 or additional WORM logic controllers 80.The WORM logic controller 20 is the only channel through whichapplications can read data on or write data to the rewritable media 60.

In one embodiment, the controller public key and the controller ID arestored in the controller certificate. The controller certificate issigned by a trusted party to prove the benevolentness of the WORM logiccontroller 20. The WORM logic controller 20 passes the controllercertificate to any entity requiring authentication of the WORM logiccontroller 20.

In another embodiment, the WORM logic controller 20 is tamper-resistantto further avoid exposure of the controller public/private key pair.However, since the controller public/private key pair is kept within theWORM logic controller 20 and is not exposed to any other software oruser, it is difficult to steal the controller public/private key pairfrom software channels. Tamper-resistance of the WORM logic controller20 is necessary only if the probability of physical intrusion is high.In most applications of the WORM storage system 100, tamper-resistancefor the WORM logic controller 20 is not required to achieve a securevirtual binding 65.

System 10 utilizes an encrypted content signature comprising a hash ofdata content (a content hash, for example a SHA-1 hash) to avoid trafficsnooping and alternation between the WORM logic controller 20 and therewritable media 60. The hash of the data content generates an encryptedcontent signature that certifies the validity of the bytes received bythe rewritable media 60. Periodically, the content hash of these bytesis sent to the WORM storage module 25. The content hash is a uniqueencrypted content signature of the bytes that the content hash verifies.Furthermore, the content hash is encrypted using the controller privatekey of the WORM logic controller 20.

The WORM storage module 25 decrypts the encrypted content signature andverifies the bytes and command codes received from the WORM logiccontroller 20. Similarly, to defeat traffic alternation from therewritable media 60 to the WORM logic controller 20, the WORM logiccontroller 20 verifies the received bytes from the rewriteable media 60.The WORM storage module 25 computes an encrypted operations signaturefor the results for any operations before sending the results back tothe WORM logic controller 20. The encrypted operations signature iscomputed based on the storage private key of the WORM storage module 25.The WORM logic controller 20 trusts only those results with matchingsignatures.

FIG. 2 illustrates a method 250 of operation of system 10. Method 250comprises an initialization phase (step 205), a registration andauthentication phase (method 300, further described in FIG. 3), anoperation phase (method 400, further described in FIG. 4), a maintenanceand management phase (method 500, further described in FIG. 5), and amigration phase (method 600, further described in FIG. 6).

The initialization phase (step 205) comprises initializing the WORMlogic controller 20 or the security-enhanced storage enclosure 35. Thesecurity-enhanced storage enclosure 35 is shipped from the manufacturerwith a storage user table that is blank and the registration flag set to“open”. The WORM logic controller 20 is shipped from the manufacturerwith the controller public/private key pair un-initialized. The customerinitializes the controller public/private key pair when the WORM logiccontroller 20 is received. The manufacturer sets the controller ID tothe serial number of the WORM logic controller 20.

FIG. 3 (FIGS. 3A, 3B, 3C) illustrates a method 300 of the registrationand authentication phase of system 10 in which a newly arrivedsecurity-enhanced storage enclosure 35 is detected by the WORM logiccontroller 20. The security-enhanced storage enclosure 35 is connectedto the WORM storage system 100 (step 305). The WORM logic controller 20detects the arrival of the security-enhanced storage enclosure 35 (step310).

System 10 performs a mutual authentication phase for the WORM storagemodule 25 and the WORM logic controller 20. The WORM storage module 25retrieves the controller public key of the WORM logic controller 20(step 315). The controller authenticator 40 authenticates the WORM logiccontroller 20 (step 320).

To authenticate the WORM logic controller 20, the controllerauthenticator 40 encrypts a challenge string with the controller publickey of the WORM logic controller 20 and sends the controller public keyto the WORM logic controller 20. A genuine, verifiable WORM logiccontroller 20 is able to decode the encrypted challenge and return thedecoded challenge to the controller authenticator 40 as proof. If thecontroller authenticator 40 cannot authenticate the WORM logiccontroller 20 (decision step 325), the authentication phase aborts (step330). Otherwise, the authentication phase continues.

The controller authenticator 40 determines whether the retrievedcontroller public key is in the storage user table of the WORM storagemodule 25 (decision step 335). If yes, the WORM storage module 25unlocks the rewritable media 60 for access by the WORM logic controller20 (step 340). If the retrieved controller public key is not in thestorage user table of the WORM storage module 25 (decision step 345),the WORM logic controller 20 has not registered with the WORM storagemodule 25.

The WORM storage module 25 determines whether registration criteria havebeen met (decision step 345). The registration criteria require that thesecurity-enhanced storage enclosure 35 is blank and the registrationflag is “open”. If the registration criteria are not met, theauthentication phase aborts (step 330). Otherwise, the controllerauthenticator 40 adds the controller public key of the WORM logiccontroller 20 to the storage user table (step 350).

The security-enhanced storage enclosure 35 may be brand new or partiallyused. If the security-enhanced storage enclosure 35 is brand new with anempty storage user table, the registration flag of the WORM storagemodule 25 is in “open” mode. When the registration flag is in “open”mode, the WORM storage module 25 allows addition of any WORM logiccontroller 20 to the storage user table. Once data is written to therewritable media 60, the WORM storage module 25 switches theregistration flag to “closed” mode and disallows admission of any newWORM logic controllers 80. Any authorized WORM logic controller 20 canset the registration flag.

To provision for fault tolerance and provide a multi-path WORM storagesystem 100, additional WORM logic controllers 80 can register with thesecurity-enhanced storage enclosure 35 while registration is open. Oncethe registration is closed, no additional WORM logic controllers 80 canbe admitted. This requirement disables registration by maliciouscontrollers intent on tampering with the data in the security-enhancedstorage enclosure 35. Consequently, to accommodate potential failure bythe WORM logic controller 20, the security-enhanced storage enclosure 35is over-provisioned with WORM logic controllers 80 before theregistration for the security-enhanced storage enclosure 35 is closed.In another embodiment, over-provisioning can be avoided by acertificate-based authentication, as it will be explained below.

To enable flexible capacity scale-up, system 10 allows thesecurity-enhanced storage enclosure 25 to register at any time with theWORM logic controller 20. When the WORM logic controller 20 registers abrand new security-enhanced storage enclosure 35, the WORM logiccontroller 20 formats and overwrites all the existing data on therewritable media 60 of the newly registered security-enhanced storageenclosure 35. This formatting procedure avoids polluting data already inthe WORM storage system 100 with the data on the newly introducedsecurity-enhanced storage enclosure 35. If the WORM storage module 25has been previously registered, the WORM logic controller 20 does notformat the data on rewritable media 60.

In one embodiment, the WORM logic controller 20 proves a legitimateidentity or trustworthiness to enable on-demand registration for theWORM logic controller 20 in which registration is always open for thesecurity-enhanced storage enclosure 35. The registration phase for thestorage enclosure is always on, in this embodiment. Hence, noover-provisioning is necessary. To prove the legitimate identity of theWORM logic controller 20, the controller public key and the controllerID are stored in a certificate signed by a trusted manufacturer. Thetrusted manufacturer encrypts the certificate with the private key ofthe manufacturer. This certificate cannot be altered since only themanufacturer knows the private key of the manufacturer. The public keyof the manufacturer is known to all.

The security-enhanced storage enclosure 35 can verify legitimacy of theWORM logic controller 20 comprising a certificate. The WORM storagemodule 25 decodes the certificate with the public key of themanufacturer. The controller authenticator 40 authenticates the WORMlogic controller 20. A malicious WORM logic controller 20 attempting toreplicate the certificate fails authentication because the maliciousWORM logic controller 20 does not have the private key that matches theencrypted public key.

Method (or process) 300 continues at step 355 wherein the WORM logiccontroller module storage authenticator 30 retrieves the storage publickey from the WORM storage module 25. The storage authenticator 30authenticates the WORM storage module 25 (step 360).

At decision step 365, method 300 inquires if such authentication wassuccessful. If it was not, then method 300 terminates at step 370.Otherwise, method 300 proceeds to decision step 375 and inquires if theretrieved public key in found in the controller user table. If it is,the controller is unlocked at step 380. Otherwise, method 300 proceedsto step 385, to format the storage and to add the storage public key tothe controller user table of the storage.

FIG. 4 illustrates a method 400 of system 10 in accessing the rewritablemedia 60 of the security-enhanced storage enclosure 35. The controllerauthenticator 40 and the storage authenticator 30 perform mutualauthentication (step 405), as described by method 300 of FIG. 3. Ifauthentication fails (decision step 410), the WORM storage module 25denies access to the WORM logic controller 20 (step 415).

If authentication succeeds (decision step 410), the WORM storage module25 receives a command such as, for example, a write request (step 420).The controller authenticator 40 periodically authenticates the datastream from the WORM logic controller 20 (step 425). If theauthentication of the data stream is invalid (decision step 430), theWORM storage module 25 fails the command execution (step 435), and thestorage is locked from further access from the command sender. If theauthentication of the data stream is valid (decision step 430), the WORMstorage module 25 executes the command on the rewritable media 60 (step440).

FIG. 5 (FIGS. 5A, 5B) illustrates a method 500 of system 10 inperforming the maintenance and management phase. A user begins themaintenance and management phase (step 505). If the user is adding a newsecurity-enhanced storage enclosure 35 (decision step 510), system 10performs the registration phase of method 300 in FIG. 3 (step 515). Ifthe user is adding a new WORM logic controller 20 (decision step 520),system 10 performs the registration phase of method 300 in FIG. 3 (step525).

If the user is removing a broken storage enclosure 35 (decision step530), the WORM logic controller 20 removes the storage public key of thebroken security-enhanced storage controller 35 from the controller usertable (step 535). A new security-enhanced storage enclosure 35 can beinstalled in the WORM storage system 100 to replace the brokensecurity-enhanced storage enclosure 35. The new security-enhancedstorage enclosure 35 follows the new security-enhanced storage enclosure35 addition procedure as described in step 510 through 515.

If the user is removing a working storage enclosure 35 (decision step540), the security-enhanced storage enclosure 35 detects thedisconnection of the WORM logic controllers 80 and marks the disconnectevent (step 545), and disallows any further access by the WORM logiccontrollers 80. When the security-enhanced storage enclosure 35 isreinstalled in the WORM storage system 100, system 10 performs theauthentication phase as described in method 300 of FIG. 3.

If the user is removing a broken WORM logic controller 20 (decision step550), the WORM storage module 25 removes the controller public key ofthe broken WORM logic controller 20 from the storage user table (step555). When a WORM logic controller 20 fails, a registered sibling WORMlogic controller provides data access to the rewritable media 60.

If the user is removing a working WORM logic controller 20 (decisionstep 560), the WORM storage module 25 detects the removal (step 565)either through notification by system 10 or after a period of idle timeby the removed WORM logic controller 20. The WORM storage module 25unlocks the data access of the rewritable media 60 from the disconnectedWORM logic controller 20 (step 570). When the WORM logic controller 20is reinstalled in the WORM storage system 100, the system 10 performsthe authentication phase as described in method 300 of FIG. 3. System 10ends the maintenance and management phase (step 575).

FIG. 6 illustrates a method 600 of system 10 in performing a migrationphase. System 10 disconnects the virtual binding (step 605). If the useris migrating the security-enhanced storage enclosure 35 (decision step610), the WORM logic controller 20 removes the controller public keyfrom the storage user table (step 615). System 10 registers the storageenclosure 35 in a “new” location as describe by method 300, FIG. 3. The“new” location may be logically new rather than physically new. Step 615and 620 apply to the embodiment in which a WORM logic controller 20 hasa signed certificate from a trusted manufacturer and registration isalways open.

In the embodiment in which registration closes after an initial byte ofuseful data is written to the security-enhanced storage enclosure 35, apartially written, working security-enhanced storage enclosure 35 canonly quit association with one WORM logic controller 20. In thisembodiment, the partially written, working security-enhanced storageenclosure 35 cannot admit a new WORM logic controller 20.

If the user is migrating the WORM logic controller 20 (decision step625), the WORM logic controller 20 notifies the security-enhancedstorage enclosure 35. The security-enhanced storage enclosure 35 removesthe controller public key from the storage user table (step 630). TheWORM logic controller 20 can register with any other security-enhancedstorage enclosure 35 in a “new” location (step 635). The “new” locationmay be logically new rather than physically new. System 10 ends themigration phase (step 640).

It is to be understood that the specific embodiments of the inventionthat have been described are merely illustrative of certain applicationsof the principle of the present invention. Numerous modifications may bemade to the system and method for providing a virtual binding for a WORMstorage system on rewritable media described herein without departingfrom the spirit and scope of the present invention.

1. A method of providing a virtual binding for a WORM storage system ona rewritable media, comprising: storing within each of a WORM logiccontroller and a WORM storage module of a security-enhanced storageenclosure, a stored public key and a stored private key; registering theWORM logic controller on the WORM storage module by detecting thepresence of the security enhanced storage enclosure; authenticating theWORM logic controller by the WORM storage module wherein authenticatingincludes decoding an encrypted challenge using the public key at theWORM logic controller issued by a controller authenticator in the WORMstorage module; authenticating the WORM storage module by the WORM logiccontroller wherein a storage authenticator in the WORM logic controllerretrieves the stored public key from the WORM storage module andverifies the public key from the WORM storage module matches the publickey from the WORM logic controller; and executing a command on therewriteable media stored within the security enhanced enclosure.
 2. Themethod of claim 1, wherein the WORM logic controller comprises acontroller memory and the storage authenticator for authenticating theWORM storage module.
 3. The method of claim 2, further comprisingstoring, in the controller memory, a controller user table, a controllerpublic key, and a controller private key, to verify the identity of theWORM logic controller.
 4. The method of claim 2, further comprisingstoring, in the controller memory, a controller ID and a certificate toauthenticate the identity of the WORM logic controller.
 5. The method ofclaim 1, wherein the controller memory is a rewritable non-volatilememory.
 6. The method of claim 3, wherein the WORM storage modulecomprises a storage memory storing the public and private key.
 7. Themethod of claim 6, further comprising storing, in the storage memory, astorage user table, and a registration flag.
 8. The method of claim 7,wherein the storage memory is a rewritable non-volatile memory.
 9. Themethod of claim 1, wherein initializing the WORM logic controller andthe WORM storage module comprises setting a registration flag includedwithin each of the WORM logic controller and a WORM storage module toopen.
 10. The method of claim 4, wherein the controller ID is set to aserial number of the WORM logic controller by a manufacturer.
 11. Themethod of claim 3, wherein the controller public key and private key areinitialized by a client.
 12. The method of claim 3, wherein registeringthe WORM logic controller on the WORM storage module comprises the WORMlogic controller retrieving the controller public key.
 13. The method ofclaim 7, wherein authenticating the WORM logic controller and the WORMstorage module comprises checking for the controller public key in thestorage user table.
 14. The method of claim 3, wherein authenticatingthe WORM logic controller and the WORM storage module comprises checkingfor the storage public key in the controller user table.
 15. The methodof claim 1, wherein executing the command on the rewriteable mediacomprises the WORM storage module receiving a command from the WORMlogic controller.
 16. A computer program product having program codesstored on a computer-usable medium for providing a virtual binding for aWORM storage system on a rewritable medium, comprising: a program codefor initializing registration information of a WORM logic controller anda WORM storage module of a security-enhanced storage enclosure; aprogram code for registering the registration information of the WORMlogic controller on the WORM storage module; a program code for mutuallyauthenticating the WORM logic controller and the WORM storage moduleaccording to registration criteria associated with the WORM logiccontroller and a public key stored in the WORM storage module; and aprogram code for executing a command on the rewriteable medium uponmutual authentication of the WORM logic controller and the WORM storagemodule.
 17. The computer program product of claim 16, wherein the WORMlogic controller comprises a controller memory and a storageauthenticator for authenticating the security-enhanced storageenclosure.
 18. The computer program product of claim 17, furthercomprising a program code for storing, in the controller memory, acontroller user table, a controller public key, and a controller privatekey, to verify the identity of the WORM logic controller.
 19. Thecomputer program product of claim 18, further comprising a program codefor storing, in the controller memory, a controller ID and a certificateto further verify the identity of the WORM logic controller.
 20. Thecomputer program product of claim 17, wherein the controller memory is arewritable non-volatile memory.
 21. The computer program product ofclaim 16, wherein the WORM storage module comprises a storage memory anda controller authenticator.